Business enterprises use IT systems as a mechanical advantage through automation of apriori well-defined repetitive operational tasks. With past dynamics of business being low, business applications were developed primarily to deliver certainty in a fixed operating environment. Advent of internet leading to increased connectivity within and amongst enterprises, and rapid evolution of technology platforms have contributed to significant increase in business dynamics in recent years. The increased dynamics puts new demands on businesses while opening up new opportunities that need to be addressed in an ever-shrinking time window. Stability and robustness seem to be giving way to agility and adaptiveness. This calls for a whole new perspective for designing (and implementing) IT systems so as to impart these critical properties.
Traditional business applications typically end up hard-coding the operating context in their implementation. As a result, adaptation to a change in its operating environment leads to opening up of application implementation. This adaptation process results in unacceptable responsiveness. It should be possible to configure a business application for the desired operating environment. New opportunities may put unconceived demands on business applications. It should be possible to quickly extend the existing implementation without breaking parts unrelated to the desired extension. It should be possible to support such adaptations at different levels of latency i.e. application design-time, application installation-time and application run-time. Moreover, large enterprises may want to impose some discipline in introducing such adaptations through, say, roles-n-responsibility structure.
Database intensive enterprise applications are realized conforming to distributed architecture paradigm that requires diverse set of technology platforms to implement. Such applications can be seen to vary along five dimensions, namely, Functionality (F), Business process (P), Design decisions (D), Architecture (A) and Technology platform (T).
A purpose-specific implementation makes a set of choices along the above mentioned dimensions, and encodes these choices, typically, in a scattered and tangled manner as mentioned in reference number 7 of the prior-art references. This scattering and tangling is the principal obstacle in agile adaptation of existing implementation for the desired change. Large size of enterprise application further exacerbates this problem. This is an expensive and error prone process demanding large teams with broad-ranging expertise in business domain, architecture and technology platforms. Model-driven development alleviates the problem somewhat by automatically deriving an implementation from its high-level specification as mentioned in reference number 17 of the prior-art references. Generation of model-based code generators from their high-level specifications further refines the solution as mentioned in reference number 18 of the prior-art references.
For identical business intent, different enterprises, even from the same business domain, may have different requirements along the above five dimensions—one can expect a significant overlap in their requirements and hence in specifications. Being ignorant of the similarities in such specifications would mean rework, and result in specification redundancy which will create maintenance and evolution problems later. Thus, it is important to capture commonality while highlighting the variability i.e. productline architecture as mentioned in reference number 9 of the prior-art references.
Specification-based development imparts adaptiveness, to a certain extent, especially with respect to technology platforms. The same business functionality can be delivered into a different set of choices of design decisions, architecture and technology platform through code generation—this is akin to retargetable code generation in compilers as mentioned in reference number 1 of the prior-art references.
However, imparting adaptation through code generation addresses the issue only in part as the ‘adapted system’ still needs to be compiled and deployed for execution. Thus, in specification-based development approaches, adaptiveness needs to be supported at various levels, namely, specification, code generation, code and deployment. Model-driven development aided by a code-generator product line imparts adaptiveness and variability with respect to D, A and T dimensions as mentioned in reference number 19 of the prior-art references.
However, change requests along D, A and T dimensions are relatively infrequent as compared to those along F and P dimensions. Ongoing dynamic middleware related work by OSGi community as mentioned in reference numbers 13 and 14 of the prior-art references which are aimed at addressing adaptiveness at deployment level.
The (de)composition mechanisms such as aspects as mentioned in reference number 7 of the prior-art references, mixins as mentioned in reference number 15 of the prior-art references, fractals as mentioned in reference number 16 of the prior-art references etc; variability management mechanisms such as feature models, and change specification languages such as ChangeBox as mentioned in reference number 12 of the prior-art references, ClassBox as mentioned in reference number 3 of the prior-art references, Jx/J& as mentioned in reference number 11 of the prior-art references are aimed at addressing adaptiveness at code level.
Some of the prior-arts known to us that address the problem of developing the database intensive business application product lines are:
U.S. Pat. No. 7,152,228 filed by Goodwin et al teaches that a method for generating source code objects has steps of generating a translation file containing translation logic; inputting the translation file into a code generator; and generating translation source code as a function of the translation file. A system for accessing a database through a translation layer comprising a first database; a translation layer, defined by translation source code; and an application for accessing the first database through the translation layer. But it fails to disclose the developing the database intensive business applications for two or more different enterprises from the same business domain from the common database intensive business application.
United States Publication Number 20080133303 filed by Singh et al teaches that a business object model, which reflects data that is used during a given business transaction, is utilized to generate interfaces. This business object model facilitates commercial transactions by providing consistent interfaces that are suitable for use across industries, across businesses, and across different departments within a business during a business transaction. But it fails to disclose the developing the database intensive business applications for two or more different enterprises from the same business domain from the common database intensive business application.
Kulkarni et al. in “Generating enterprise applications from models-experience and best practices” discloses about a family of tool-sets wherein each member takes one application specification as an input and gives implementation of that specification as an output in a particular architecture. Still it doesn't address the specification redundancy, while generating a set of closely related applications that leads to the maintenance and evolution problem.
Grady Booch in “The architecture of Web applications” teaches that a standard architecture for the web applications. The developed web application can be deployed on that standard architecture. But it fails to disclose the deployment of the developed database intensive business application in that standard architecture.
Rahul Mohan et al. in “Model Driven Development of Graphical user Interfaces for Enterprise Business applications a Experience, Lessons Learnt and a Way forward” discloses about applying model-driven techniques to build Graphical User Interfaces (GUI) of large enterprise business applications. The approach involves capturing various user interface patterns in the form of platform independent parameterized templates and instantiating them with relevant application data, serving as the template arguments. Models thus instantiated are translated to platform specific GUI implementation artifacts by a set of template-specific code generators. But it does not address the problem of specification redundancy, while generating a set of closely related application GUIs that leads to the maintenance and evolution problem.
Xuehong Du et al. in “Product family modeling and design support: An approach based on graph rewriting systems” discloses about a graph rewriting system to organize product family data according to the underpinning logic and to model product derivation mechanisms for product family design (PFD). It represents the structural and behavioral aspects of product families as family graphs and related graph operations, respectively. The derivation of product variants becomes a graph rewriting process, in which family graphs are transformed to variant graphs by applying appropriate graph rewriting rules. But it does not address the problem of specification redundancy, while generating a set of closely related applications that leads to the maintenance and evolution problem.
More particularly, the shortcomings with the prior arts are that the computational cost as well computational time is high for creating new database intensive business applications for different enterprises, even though from the same business domain. Yet another shortcoming with the prior arts is maintenance and evolution problems for creation of new database intensive business applications for different enterprises, even though from the same business domain due to significant overlap in their requirements and in specifications. Being ignorant of this overlap would mean rework, and result in specification redundancy. Yet another shortcoming with the prior arts are that they could not able provide a deployment framework for testing the developed database intensive business application.
Thus, in the light of the above mentioned prior art, it is evident that the computationally efficient system for developing configurable, extensible database intensive business application product lines for different enterprises, from the same business domain.